home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 599 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. Path: chronicle.mti.sgi.com!austern
  2. From: "ian (i.) willmott" <willmott@bnr.ca>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Generic Object Callbacks
  5. Date: 29 Feb 1996 19:25:37 PST
  6. Organization: Northern Telecom
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4h5j7b$1ur@bcarh8ab.bnr.ca>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Original-Date:  Fri, 1 Mar 1996 01:17:31 +0000 
  14. Content-Identifier:  Re: Generic O... 
  15. X-Mailer: Mozilla 1.1 (X11; I; HP-UX A.09.05 9000/720) 
  16. X-Url: news:3135C73D.5570@acf4.nyu.edu 
  17. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  18.     iQBVAwUBMTZuUUy4NqrwXLNJAQEIwQH+Ib9kreglGeLh/dTCgohXw9vMIj+izYfH
  19.     MZ8up2dV7nPzghc3mGYDwjCQwQ7ghbApyg3t0HkDwBAgpYdBZhtSMw==
  20.     =bUZa
  21. Originator: austern@isolde.mti.sgi.com
  22.  
  23. Shalom Reich <sqr1874@acf4.nyu.edu> wrote:
  24.  
  25. >I don't seem to understand the discussion in this thread.  Yet it seems to generate 
  26. >some strong opinions.  So, . . . 
  27. >
  28. >The routine that will issue the callback (let us call it the driver) needs to use a
  29. >stored pointer.  The argument is that the stored pointer should be to a member function.  
  30. >Why isn't it good enough for the stored pointer to be a pointer to the object and then 
  31. >the driver will only need to say "object->callback();" in order to call the proper routine.
  32. >The usual virtual function semantics would take care of any inheritance hierarchy.
  33.  
  34. The point is that the "driver" shouldn't have to know the type of the object the
  35. callback is directed at. This is particularly important when the "driver" issuing
  36. the callback is a library API, such as Motif; you do not want the library to have
  37. to know about application data types and you do not want to constrain the application
  38. to use a single callback object type that is defined by the library. The point of the
  39. proposal is that there is a simple extension to the language which would accomplish
  40. this in a type-safe way.
  41.  
  42. >If the driver could deal directly with the address of a non-static member function 
  43. >how would the "this" parameter be supplied by the caller?
  44.  
  45. The original article (this has expired on my site and possibly others as well;
  46. maybe I should repost it) suggests a new type "pointer-to-bound-member-function"
  47. which would encapsulate an object pointer and a pointer to a member function
  48. of that class.
  49.  
  50. >The X example seems to be showing an inteface between a C environment and a C++
  51. >environment.  Is that the real problem?
  52.  
  53. The real problem is that it's difficult to write an object-oriented API for a
  54. system like X because C++ as currently defined doesn't provide type-independent
  55. object callbacks. The proposed language extension would greatly facilitate the
  56. creation of object-oriented, event-driven API's.
  57.  
  58. >Am I missing something here?
  59.  
  60. See my original article for an extended discussion of this issue. I will repost it
  61. or email it if necessary.
  62.  
  63. Ian Willmott
  64. Bell-Northern Research
  65. Ottawa, Ontario
  66. (613)-763-9688
  67. willmott@bnr.ca
  68. ---
  69. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  70.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  71.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  72.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  73.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  74. ]
  75.